\documentclass[12pt]{article}

\usepackage[english]{babel}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage{graphicx}
\usepackage{pdfpages}
\usepackage{fancyhdr}
\usepackage{amsmath}
\usepackage{setspace}
\usepackage{listings}
\usepackage[normalem]{ulem}
\usepackage[font=footnotesize,format=plain,labelfont=bf,up,textfont=it,up,justification=centering]{caption}
\usepackage[hidelinks]{hyperref}
\usepackage{pdflscape}
\setlength{\textwidth}{481pt} % Largeur de la zone de texte (17cm)
\setlength{\oddsidemargin}{0pt} % Marge gauche sur pages impaires
\setlength{\evensidemargin}{0pt} % Marge gauche sur pages paires
\setlength{\topmargin}{0pt} % Pas de marge en haut
\setlength{\headheight}{12pt} % Haut de page
\setlength{\headsep}{25pt} % Entre le haut de page et le texte
\setlength{\footskip}{30pt} % Bas de page + séparation
\setlength{\textheight}{620pt} % Hauteur de la zone de texte (25cm)
\setlength{\parindent}{0cm}
\setstretch{1.2}

\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{3}
\makeatletter
\newcounter {subsubsubsection}[subsubsection]
\renewcommand\thesubsubsubsection{\thesubsubsection .\@alph\c@subsubsubsection}
\newcommand\subsubsubsection{\@startsection{subsubsubsection}{4}{\z@}%
                                     {-3.25ex\@plus -1ex \@minus -.2ex}%
                                     {1.5ex \@plus .2ex}%
                                     {\normalfont\normalsize\bfseries}}
\newcommand*\l@subsubsubsection{\@dottedtocline{3}{10.0em}{4.1em}}
\newcommand*{\subsubsubsectionmark}[1]{}
\makeatother

%Page de garde
\makeatletter
\def\clap#1{\hbox to 0pt{\hss #1\hss}}%
\def\ligne#1{%
\hbox to \hsize{%
\vbox{\centering #1}}}%
\def\haut#1#2#3{%
\hbox to \hsize{%
\rlap{\vtop{\raggedright #1}}%
\hss
\clap{\vtop{\centering #2}}%
\hss
\llap{\vtop{\raggedleft #3}}}}%
\def\bas#1#2#3{%
\hbox to \hsize{%
\rlap{\vbox{\raggedright #1}}%
\hss
\clap{\vbox{\centering #2}}%
\hss
\llap{\vbox{\raggedleft #3}}}}%
\def\maketitle{%
\thispagestyle{empty}\vbox to \vsize{%
\haut{}{\@blurb}{}
\vfill
\vspace{1cm}
\begin{flushleft}
%\usefont{OT1}{ptm}{m}{n}
\huge \@title
\end{flushleft}
\par
\hrule height 3pt
\par
\begin{flushright}
%\usefont{OT1}{phv}{m}{n}
\large \@author
\par
\end{flushright}
\vspace{1cm}
\vfill
\vfill
\bas{}{\@location\ - \@date}{}
}%
\cleardoublepage
}
\def\date#1{\def\@date{#1}}
\def\author#1{\def\@author{#1}}
\def\title#1{\def\@title{#1}}
\def\location#1{\def\@location{#1}}
\def\blurb#1{\def\@blurb{#1}}
\date{\today}
\author{}
\title{}
\blurb{}
\makeatother
\title{Design Document\\\Large MeteoCal}
\author{Adrien \textsc{Bestel}\\Jorge \textsc{Vera}\\}
\location{Milano}




\date\today

\begin{document}
\newpage
\begin{figure}[t]
        \includegraphics[height = 20mm]{logo.png}
\end{figure}
\vspace{-15cm}
\maketitle
\thispagestyle{empty}
\newpage
\tableofcontents
\newpage
\pagestyle{fancy}
\renewcommand{\headrulewidth}{0.01mm}
\lhead{\footnotesize Adrien \textsc{Bestel} - Jorge \textsc{Vera}}
\rhead{\footnotesize Design Document - MeteoCal}

\lstset{language=Java}

\clearpage
\section*{Change log}

\begin{itemize}
	\item \textbf{07/01/2015} : Changed the conceptual design of the database. A problem was corrected with the proposed schema of the Notifications and of the Events.
\end{itemize}

\clearpage
\section{Architecture Description}

As stated in the Requirements Analysis and Specification Document delivered  two weeks ago, this project will be developed entirely using the Java Enterprise Edition (J2EE) Framework. This section will consist first in a quick presentation of J2EE, and then in the definition of the sub-systems used for the development of the MeteoCal application.

\subsection{Java Enterprise Edition}

The architecture of the application largely depends on the architecture of J2EE. The architecture of the framework is shown in Figure~\ref{fig:jeearch} below.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=13cm]{javaee.png}
		\caption{Diagram of the architecture of Java Enterprise Edition}
		\label{fig:jeearch}
	\end{center}
\end{figure}

The framework is based on four tiers, that are described below :
\begin{itemize}
	\item \textbf{Client tier}\\This tier contains every client application (Java Applications or Web Applications). It represents the only mean of interaction between the client and the system. For MeteoCal, this tier will be based on a Web Application.
	\item \textbf{Web tier}\\The Web Tier consists in the communication between the client and the business. It contains Servlets and Dynamic Pages.
	\item \textbf{Business tier}\\The Business Tier contains the Business Logic in Enterprise JavaBeans (EJB). It represents the core of the J2EE structure.
	\item \textbf{EIS tier}\\The EIS tier contains the data source. For MeteoCal, the data source will be stored in a relational database.
\end{itemize}

\subsection{Subsystems}
Using a top-down approach, sub-systems of MeteoCal have been identified. This is a useful at the beginning of a project since it allows to separate different aspects of the system, and have a clearer vision of the different components that need to be developed, and of their interactions.

\vspace{0.5cm}

The system will be composed of four first-level subsystems, which are the following (a visual representation of these subsystems is visible in Figure~\ref{fig:subsystems} on page~\pageref{fig:subsystems} below) :
\begin{itemize}
	\item \textbf{UserManagement}\\The UserManagement subsystem represents the operation a client can do to get a different status on the server. It gathers two sub-subsystems that represent \textbf{registering functions} and \textbf{log in/out functions}.
	\item \textbf{User}\\
	The User subsystem represents every functions associated to a User. It is itself separated into three sub-subsystems : \textbf{ProfileManagement} (so the ability to see profiles and to edit a profile), \textbf{CalendarManagement} (the ability to accept invitations) and \textbf{EventManagement} (the ability to create and edit an event).
	\item \textbf{Administrator}\\
	The Administrator subsystem gathers every functions associated to the status of Administrator. It is separated into two sub-subsystems : \textbf{EventAdministration} and \textbf{UserAdministration}.
	\item \textbf{Data}\\
	The last subsystem is the one that will manage the data. This subsystem will be defined with more details in Section~\ref{sec:dataManagement} \textit{\nameref{sec:dataManagement}} (see page~\pageref{sec:dataManagement}).
\end{itemize}

\begin{landscape}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=21cm]{subsystems.png}
		\caption{Diagram of the subsystems of MeteoCal}
		\label{fig:subsystems}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\section{Persistent Data Management}
\label{sec:dataManagement}

The data of the application will be stored in a relational database. The aim of this section is to describe as precisely as possible the design of the database used in the application.

\subsection{Conceptual Design}

The application needs to store relatively complex data (at least in term of relations between entities) in a permanent way (so, outside of the application : in a database). The entities and relations are detailed in an Entities/Relationship Diagram in Figure~\ref{fig:erDiagram} on page~\pageref{fig:erDiagram} below.

\vspace{0.5cm}

The schemata is consistent with the UML Class Diagram presented in the Requirements Analysis and Specification Document redacted earlier in the project.

\vspace{0.5cm}

To avoid any misunderstanding of the diagram, here is a description of every entity :
\begin{itemize}
	\item \textbf{Abstract User}\\This entity defines a user of the system. It is represented by an email (the primary key), a password (that will be encrypted for security reasons) and an avatar.
	\item \textbf{User}\\This entity represents a regular user of the system. Each user has a profile with some information like the first name, the last name, the gender, the living place and if the User has been banned or not.
	\item \textbf{Administrator}\\The Administrator is a particular user that has access to advanced functions. There is no particular information about the Administrator, it is a representation of a status.
	\item \textbf{Calendar}\\A Calendar is the liaison between a User and its Events. Its only attribute is the fact that it is public or not.
	\item \textbf{Event}\\An Event is defined by the location, the date (and time), the fact that it is public or not, the need for a good weather and the name.
	\item \textbf{Forecast}\\The (weather) Forecast is represented by the type of weather forecast (rainy, sunny, cloudy...), by a confidence index and by the date of the creation of the Forecast.
	\item \textbf{Notification}\\The Notification is a communication from the server to the users about an event. Its only attribute is the fact that it has been read or not.
	\item \textbf{BadWeather}\\A BadWeather is a type of Notification that notify the organizer that there is a bad weather for one of its events and that gives a proposition of a new date with better weather if possible. 
	\item \textbf{Canceled}\\A Canceled is a type of Notification that notify the Organizer and the Invited Users that an event has been canceled, and why it has been canceled.
	\item \textbf{Invitation}\\An Invitation is a Notification sent to a user when someone has invited him to an event. It also carries the answer of the User.
\end{itemize}

\vspace{0.5cm}

Here is a description of every relation between entities :
\begin{itemize}
	\item \textbf{owns}\\One User \textbf{owns} only one Calendar. One Calendar is owned by only one User.
	\item \textbf{has}\\A Calendar \textbf{has} Events (so 0 or many). An event is present on at least one Calendar (on the Calendar of the Organizer) and can be present on many more of them (the Calendars of the invited Users).
	\item \textbf{organizer}\\An Event has only one \textbf{organizer} (which is a User). A User can organize none to many Events.
	\item \textbf{invited}\\None to many Users are \textbf{invited} to an Event. One User can be invited from none to many Events.
	\item \textbf{weather}\\An Event has a \textbf{weather} Forecast. A Forecast is related to only one Event.
	\item \textbf{to}\\A Notification is sent \textbf{to} one User. One User can receive from none to many Notifications.
	\item \textbf{about}\\A Notification is \textbf{about} one Event only. One event can be the source of none to many Notifications.
\end{itemize}

\begin{landscape}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=21cm]{er-diag.png}
		\caption{Entities/Relationship Diagram of MeteoCal}
		\label{fig:erDiagram}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\subsection{Logical Design}

The Entities/Relationship Diagram presented in Figure~\ref{fig:erDiagram} on page~\pageref{fig:erDiagram} is a first version of the design of the database, that needs to be refined and optimized. That is the goal of this section.

\subsubsection{Entities/Relationship Restructuring}

Here are some possible optimization of the diagram presented before :
\begin{itemize}
	\item \textbf{Abstract User, User and Administrator}\\User and Administrator are really similar entities, that extend Abstract user. The idea here is to merge the three Entities into one, and to add an attribute \textit{Type} to know if the User is an Administrator or not.
	\item \textbf{User and Calendar}\\The two entities have a 1:1 relation on both sides. They could be gathered together. But a possible (and probable) upgrade of the system would be for a User to create as much Calendar as he wants, and we want to keep this option possible without having to redefine a big part of the database. Still, a Calendar will always be associated to only one user, so there is no need to create a table \textit{Owns}, the Calendar will only keep track of the User that owns it. A User being represented by an email address (so a String), it would be more optimized to change the primary key of a User to an Integer \textit{ID} and keep the email address as a simple attribute (that needs to be marked as unique in the definition of the table). Also, an index on this field user\_id of Calendar should be created to avoid losing in too much performance.
	\item \textbf{User and Event}\\An Event has only one Organizer, so the table \textit{Organizer} is not really useful, we could keep track of the User that organizes an event directly into the Event.
	\item \textbf{Event and Forecast}\\Since weather is a 1:1 relation on both sides, we could merge the two entities and keep the attributes of Forecast into the Event directly.
	\item \textbf{Notification and Event}\\A Notification is always about an Event, so we do not have to create a table \textit{About}, we can store the ID of the Event directly into the Notification as an attribute.
	\item \textbf{Notification and User}\\A Notification is always sent to one User only, so we do not have to create a table \textit{to}, we can store the ID of the User directly into the Notification as an attribute.
	\item \textbf{Notification, BadWeather, Canceled and Invitation}\\The four classes are relatively similar. It is better to merge them into one, keep the attributes of every type of Notification, and add an attribute \textit{Type} into the entity Notification.
\end{itemize}

\subsubsection{Translation to Logical Model}

The Logical Model of the database associated to MeteoCal is then the described below (primary key are underlined, foreign keys are in italic) :
\begin{itemize}
	\item \textbf{User} (\uline{ID}, EmailAddress, Password, Avatar, FirstName, LastName, Gender, LivingPlace, Banned, Type)
	\begin{itemize}
		\item \texttt{ID} : Integer
		\item \texttt{EmailAddress} : String
		\item \texttt{Password} : String
		\item \texttt{Avatar} : Image
		\item \texttt{FirstName} : String
		\item \texttt{LastName} : String
		\item \texttt{Gender} : Enum['Male', 'Female', 'Other']
		\item \texttt{LivingPlace} : String
		\item \texttt{Banned} : Boolean
		\item \texttt{Type} : Enum['Administrator', 'RegularUser']
	\end{itemize}		
	
	\item \textbf{Calendar} (\uline{ID}, IsPublic, \textit{OwnerId})
	\begin{itemize}
		\item \texttt{ID} : Integer
		\item \texttt{IsPublic} : Boolean
		\item \texttt{OwnerID} : Integer | $\mbox{OwnerID} \in \mbox{User.ID}$
	\end{itemize}		
	
	\item \textbf{Event} (\uline{ID}, Name, IsPublic, NeedsGoodWeather, Date, Location, \textit{OrganizerID}, ForecastIndex, ForecastType, ForecastDate)
	\begin{itemize}
		\item \texttt{ID} : Integer
		\item \texttt{Name} : String
		\item \texttt{IsPublic} : Boolean
		\item \texttt{NeedsGoodWeather} : Boolean
		\item \texttt{Date} : DateTime
		\item \texttt{Location} : String
		\item \texttt{OrganizerID} : Integer | $\mbox{OrganizerID} \in \mbox{User.ID}$
		\item \texttt{ForecastIndex} : Integer
		\item \texttt{ForecastType} : Enum['Good', 'Bad']
		\item \texttt{ForecastDate} : DateTime
	\end{itemize}
	
	\item \textbf{Notification} (\uline{ID}, Read, \textit{EventID}, Type, Proposition, Reason, Answer)
	\begin{itemize}
		\item \texttt{ID} : Integer
		\item \texttt{Read} : Boolean
		\item \texttt{EventID} : Integer | $\mbox{EventID} \in \mbox{Event.ID}$
		\item \texttt{UserID} : Integer | $\mbox{UserID} \in \mbox{User.ID}$
		\item \texttt{Type} : Enum['BadWeather', 'Canceled', 'Invitation']
		\item \texttt{Proposition} : DateTime
		\item \texttt{Reason} : String
		\item \texttt{Answer} : Boolean
	\end{itemize}
	
	\item \textbf{hasEvents} (\uline{\textit{CalendarID}, \textit{EventID}})
	\begin{itemize}
		\item \texttt{CalendarID} : Integer | $\mbox{CalendarID} \in \mbox{Calendar.ID}$
		\item \texttt{EventID} : Integer | $\mbox{EventID} \in \mbox{Event.ID}$
	\end{itemize}
	
	\item \textbf{invitedTo} (\uline{\textit{UserID}, \textit{EventID}})
	\begin{itemize}
		\item \texttt{UserID} : Integer | $\mbox{UserID} \in \mbox{User.ID}$
		\item \texttt{EventID} : Integer | $\mbox{EventID} \in \mbox{Event.ID}$
	\end{itemize}
\end{itemize}

\vspace{0.5cm}

On Figure~\ref{fig:erDiagramOpt} below is represented the optimized Entities/Relationship diagram taking into account every optimization described in this section.

\begin{landscape}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=21cm]{er-diag-opt.png}
		\caption{Optimized Entities/Relationship Diagram of MeteoCal}
		\label{fig:erDiagramOpt}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\section{User Experience}

This section aims at describing the User Experience expected on the web application of MeteoCal in a more technical approach than in the Requirements Analysis and Specification Document delivered earlier.

\vspace{0.5cm}

Class Diagrams and Wire Frames (based on the Bootstrap Framework) will be used to describe the user interface. The Class Diagrams are composed of normal classes and specific classes designed to describe the user interface, using the following stereotypes :
\begin{itemize}
	\item \textbf{<<screen>>} : a screen is an entire page, a web page in the case of MeteoCal.
	\item \textbf{<<screen compartment>>} : this stereotype represents a part of a page that can possibly be shared with other pages.
	\item \textbf{<<input form>>} : an input form is a form that needs to be filled by a user and sent to the server through a click on a button.
\end{itemize}

\subsection{Home Page}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=10cm]{Login.png}
		\caption{Default Home Page}
		\label{fig:loginPage}
	\end{center}
\end{figure}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=10cm]{Register.png}
		\caption{Default Home Page with register form}
		\label{fig:registerPage}
	\end{center}
\end{figure}

The Home Page is the page where a Guest lands when going on the web application. The default Home Page is represented on Figure~\ref{fig:loginPage} (page~\pageref{fig:loginPage}). On this Home Page, three interactions are possible :
\begin{itemize}
	\item \textbf{Login}\\This function is based on an input form visible on Figure~\ref{fig:loginPage}. The user only has to fill its email address and its password, then click on the button \texttt{Login}, that will redirect him on the \texttt{Home Page} in case of error, and on the \texttt{Profile Page} in case of success.
	\item \textbf{Register}\\This interaction will update the default form into a register form visible on Figure~\ref{fig:registerPage} (page~\pageref{fig:registerPage}) (only the form is updated, not the entire page). The user then has two interactions : \textbf{Cancel} that will reload the default form, and \textbf{Confirm} that will send the user on its \texttt{Profile Page}.
	\item \textbf{Learn More}\\This button is just a link to a static page that contains a description of the service (that will not be described in this document).
\end{itemize}

\clearpage
Figure~\ref{fig:homePageUxDiagram} below represents the Class Diagram associated with the Home Page of MeteoCal. It is pretty simple since thus only functions exposed here are the registering of a new user and the login of a registered user. \texttt{ProfilePage} present here will be detailed later in the document, in Section~\ref{sec:profilePage} \textit{\nameref{sec:profilePage}} (page~\pageref{sec:profilePage}).

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{HomePage.png}
		\caption{Home Page Class Diagram}
		\label{fig:homePageUxDiagram}
	\end{center}
\end{figure}

\clearpage
\subsection{Profile Page}
\label{sec:profilePage}

After signing into the application through the Home Page, a user lands on its Profile Page. A wire frame of this page is described in Figure~\ref{fig:profilePage} below.

\vspace{0.7cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{Profile.png}
		\caption{User Profile Page}
		\label{fig:profilePage}
	\end{center}
\end{figure}

There are eight types of interactions on this page, that are the following :
\begin{itemize}
	\item \textbf{Search}\\This input field is present in the nav bar on every page restricted to a connected user. When the field is filled and the user clicks on \texttt{Search}, he is redirected to another page described in Section~\ref{sec:searchPage} \textit{\nameref{sec:searchPage}} (page~\pageref{sec:searchPage}).
	\item \textbf{See profile}\\This button is present in the nav bar on every page restricted to a connected user. It allows a user to come back to the \texttt{Profile Page}.
	\item \textbf{Log out}\\As the \texttt{Profile} button, this button is present in the nav bar on every page restricted to a connected user. It allows a user to log out. When clicking on this, the user is redirected to the \texttt{Home Page}.
	\item \textbf{See notifications}\\When a user clicks on this link, he is redirected to another web page where he can see his notifications. This page is called \texttt{Notifications Page} and is described in Section~\ref{sec:notifPage} \textit{\nameref{sec:notifPage}} (page~\pageref{sec:notifPage}).
	\item \textbf{Create event}\\When a user clicks on this link, he is redirected to another web page where he can create a new event. This page is described in Section~\ref{sec:creEvePage} \textit{\nameref{sec:creEvePage}} (page~\pageref{sec:creEvePage}).
	\item \textbf{Choose the view for events}\\A user can choose to show only its own events or only events he is going to. This only refreshes the list of events, not the whole page.
	\item \textbf{See Event}\\Every event of the events list of the Profile Page is clickable. When a user clicks on an event, he is redirected to the page dedicated to this event. This page is described in Section~\ref{sec:evePage} \textit{\nameref{sec:evePage}} (page~\pageref{sec:evePage}).
	\item \textbf{Edit/Save profile}\\The view of the profile is basically an input form locked by default. When the user clicks on the \texttt{Edit} button, it unlocks the form. When the user clicks on the \texttt{Save} button, it re-locks the form and sends the new information to the server.
\end{itemize}

\vspace{0.5cm}

Figure~\ref{fig:profilePageUxDiagram} below represents the Class Diagram associated with the Profile Page of a user. All the pages present on this diagram will be described later in this document.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{ProfilePage.png}
		\caption{Profile Page Class Diagram}
		\label{fig:profilePageUxDiagram}
	\end{center}
\end{figure}

\clearpage
\subsection{Search Page}
\label{sec:searchPage}

The nav bar contains an input field for the user to make a search for other users or events. Once this input field filled and submitted, the user lands on the Search Page. The wire frame of this page is visible on Figure~\ref{fig:searchPage} below.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{search.png}
		\caption{Search Page}
		\label{fig:searchPage}
	\end{center}
\end{figure}

On the Search Page, there are two types of interactions (the nav bar is not analyzed here) :
\begin{itemize}
	\item \textbf{Click on an event}\\Every event of the events list of the Search Page is clickable. When a user clicks on an event, he is redirected to the page dedicated to this event. This page is described in Section~\ref{sec:evePage} \textit{\nameref{sec:evePage}} (page~\pageref{sec:evePage}).
	\item \textbf{Click on a profile}\\Every profile of the profiles list of the Search Page is clickable. When a user clicks on a profile, he is redirected to the page dedicated to this user. This page is described in Section~\ref{sec:publicPage} \textit{\nameref{sec:publicPage}} (page~\pageref{sec:publicPage}).
\end{itemize}

\vspace{0.5cm}

Figure~\ref{fig:searchPageUxDiagram} below represents the Class Diagram associated with the Search Page.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=15.5cm]{SearchPage.png}
		\caption{Search Page Class Diagram}
		\label{fig:searchPageUxDiagram}
	\end{center}
\end{figure}

\clearpage
\subsection{Notifications Page}
\label{sec:notifPage}

Through his Profile Page, an user can access to a link to check its notifications. He then lands on the Notifications Page. The wire frame of this page is visible on Figure~\ref{fig:notificationsPage} below.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{Notifications.png}
		\caption{Notifications Page}
		\label{fig:notificationsPage}
	\end{center}
\end{figure}

Two new interactions appear on this page (for the interactions of the nav bar and the profile edition, check Section~\ref{sec:profilePage} \textit{\nameref{sec:profilePage}} on page~\pageref{sec:profilePage}) :
\begin{itemize}
	\item \textbf{Mark a notification as read}\\Each notification of the list has a \texttt{x} button at the top right. This will mark the notification as read event though the user has not answered it. This will just refresh the list by masking the notification.
	\item \textbf{Answer to a notification}\\Each notification of the list has some button to accept or reject a change. When clicked, the answer is sent to the server and the list is refreshed by masking the answered notification.
\end{itemize}

\vspace{0.5cm}

Figure~\ref{fig:notifPageUxDiagram} below represents the Class Diagram associated with the Notifications Page.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=15.5cm]{NotificationsPage.png}
		\caption{Notifications Page Class Diagram}
		\label{fig:notifPageUxDiagram}
	\end{center}
\end{figure}

\clearpage
\subsection{Create Event Page}
\label{sec:creEvePage}

Through his Profile Page, an user can access to a link to create a new event. He then lands on the Create Event Page. The wire frame of this page is visible on Figure~\ref{fig:createEventPage} below.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{EventCreate.png}
		\caption{Create Event Page}
		\label{fig:createEventPage}
	\end{center}
\end{figure}

Two new interactions appear on this page (for the interactions of the nav bar, check Section~\ref{sec:profilePage} \textit{\nameref{sec:profilePage}} on page~\pageref{sec:profilePage}) :
\begin{itemize}
	\item \textbf{Cancel event creation}\\When clicked, this button cancels the creation of the event and the user is redirected to his Profile Page.
	\item \textbf{Create event}\\A click on this button will run a data check on the form. In case of error (missing data for example), the form is updated to show the errors. In case of success, the user is redirected to the Event Details Page.
\end{itemize}

\vspace{0.5cm}

Figure~\ref{fig:createEventPageUxDiagram} below represents the Class Diagram associated with the Create Event Page.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{CreateEventPage.png}
		\caption{Create Event Page Class Diagram}
		\label{fig:createEventPageUxDiagram}
	\end{center}
\end{figure}

\clearpage
\subsection{Event Details Page}
\label{sec:evePage}

When a user clicks on the preview of an event, he lands on the Event Details Page. The wire frame of this page is visible on Figure~\ref{fig:eventDetailsPage} below.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{EventDetail.png}
		\caption{Event Details Page}
		\label{fig:eventDetailsPage}
	\end{center}
\end{figure}

\clearpage
Three new interactions (reserved to the owner of the event) appear on this page (for the interactions of the nav bar, check Section~\ref{sec:profilePage} \textit{\nameref{sec:profilePage}} on page~\pageref{sec:profilePage}) :
\begin{itemize}
	\item \textbf{Delete event}\\This button allows the user to delete his event (it appears only if the user if the owner of the event). Once clicked and confirmed, the event is deleted and the user is redirected to his Profile Page.
	\item \textbf{Edit/Save event}\\This button unlocks the form containing the information about the event. When the form is unlocked, clicking again on the button saves the modifications. It only refreshes the input form, not the whole page.
	\item \textbf{Check notification}\\If a BadWeather notification exists, the owner can check it by clicking on the link. He then goes straight to the Notifications Page.
\end{itemize}

\clearpage
Figure~\ref{fig:eventDetailsPageUxDiagram} below represents the Class Diagram associated with the Event Details Page.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{EventDetailsPage.png}
		\caption{Create Event Page Class Diagram}
		\label{fig:eventDetailsPageUxDiagram}
	\end{center}
\end{figure}


\clearpage
\subsection{Public Profile Page}
\label{sec:publicPage}

When a user clicks on the preview of a user, he lands on his Public Profile Page. The wire frame of this page is visible on Figure~\ref{fig:publicProfilePage} below.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{UserCalendar.png}
		\caption{Public Profile Page}
		\label{fig:publicProfilePage}
	\end{center}
\end{figure}

There are no new interactions on the page. Figure~\ref{fig:publicProfilePageUxDiagram} below represents the Class Diagram associated with the Public Profile Page.

\vspace{0.5cm}

\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=16.75cm]{PublicProfilePage.png}
		\caption{Public Profile Page Class Diagram}
		\label{fig:publicProfilePageUxDiagram}
	\end{center}
\end{figure}

\clearpage
\section{BCE Diagrams}

In this section we present the Boundary-Control-Entity diagrams, using the UML standard we show the program implementation to fulfill the use cases defined in the RASD. 

\vspace{0.5cm}

The following diagrams are not representing the whole system by they own, they are small systems that acomplish different sets of use cases and all together represent the whole system. A unified vision of the whole system is not possible to be done and be comprehensive and that is the fundamental reason we did 3 different diagrams:

\begin{itemize}
	\item \text The first diagram shows only all the different entities working in MeteoCal.
	\item \text The second diagram is a BCE diagram that implements the sufficient entities, controls and boundaries to perform the use cases for user login, user register and user logout.
	\item \text The last diagram is a BCE diagram that implements all the rest of the use cases for MeteoCal such as edit profile, create event, modify event, delete event, invite user to event, set event privacy, accept/decline invitation, check notifications, manage suggestion of a change of date, change calendar privacy, see user calendar and ban a user.
\end{itemize}

\clearpage
\begin{landscape}
\subsection{BCE Entities diagram of MeteoCal}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=18cm]{bce-1-overview.png}
		\caption{BCE Entities Diagram of MeteoCal}
		\label{fig:bceEntitiesDiagram}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\begin{landscape}
\subsection{BCE Diagram for User Login, Register and Logout of MeteoCal}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=20cm]{bce-2-login.png}
		\caption{BCE Diagram for User Login, Register and Logout of MeteoCal}
		\label{fig:bceUserDiagram}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\begin{landscape}
\subsection{BCE Diagram of Main Features of MeteoCal}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=21cm]{bce-3-program.png}
		\caption{BCE Diagram of Main Features of MeteoCal}
		\label{fig:bceMainFeatures}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\section{Sequence Diagrams}

In this section we present different sequence diagrams to explain the behavior of the MeteoCal system with it's interior entities, boundaries and controls. We only present 3 different use cases, that in extension is applied to all the other MeteoCal's use cases:

\vspace{0.5cm}

\begin{itemize}
	\item \text The Register sequence is vital for the working of the application, we need users to work with and access to their profiles, so the interaction with the guest to create a new user in the system is represented in this sequence diagram.
	\item \text The Login into the system is also important, is the only way a guest can become a user of the system, and this diagram explains the validation of the data the user put against the information in the application, once is validated the login, the gues continues into the system into his or her user profile.
	\item \text At the end, the sequence diagram of an Event Creation shows us how the different entities are related by the controls to provide the creation of a new event and to update (if possible) it's forecast. Then, after the event creation, the user is redirected to the event's page. In this diagram the use cases invite user to event and set event privacy are unified and simplified with just filling the event details by the user and then the system validates them, but is worth to mention that the sequence diagram whould be bigger and whould include both of these use cases.
\end{itemize}

\vspace{0.5cm}
For a simplification of the diagrams, the information required in different forms is asked as form of simple information, and it's validation is signalized as validated without going deeper in the way or in the full details asked for the accomplishment of a task. This is just because we focused in the interaction of the components of the system and not in each data or validation the components have to do on their own.

\clearpage
\begin{landscape}
\subsection{Register into MeteoCal Sequence Diagram}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=18cm]{sd-register.png}
		\caption{Register into MeteoCal Sequence Diagraml}
		\label{fig:RegisterSequenceDiagram}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\begin{landscape}
\subsection{Login into MeteoCal Sequence Diagram}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=20cm]{sd-login.png}
		\caption{Login into MeteoCal Sequence Diagram}
		\label{fig:LoginSequenceDiagram}
	\end{center}
\end{figure}
\end{landscape}

\clearpage
\begin{landscape}
\subsection{Create an Event into MeteoCal Sequence Diagram}
\begin{figure}[ht!]
	\begin{center}
		\includegraphics[width=21cm]{sd-createevent.png}
		\caption{Create an Event into MeteoCal Sequence Diagram}
		\label{fig:CreateEventSequenceDiagram}
	\end{center}
\end{figure}
\end{landscape}
\clearpage
\section{Final Considerations}

For the creation of this document, we have detailed the guidelines to accomplish the main goals of our MeteoCal application. The full detail to accomplish the development and deployment of the application makes no sense because the deadline for the delivery of the application is already set and the final requirements also are. This does not mean that inside the team are not deadlines to deliver an assigned job, but as it is a 2 people development should be really easy to keep track of the work done by each part. Also is important to empathise that both members of the team will have to develop lavors as project managers, programmers, designers, testers and so on, therefore there will be new responsabilities comming up that are non predictable.

\vspace{0.5cm}

Also the graphics shown in this document such as wireframes or diagrams are supposed to be changed during the development and do not represent necessarly the final implementation of the application.

\section{Hours Count}

We counted the amount of hours spent in the developing of this document, the hour count was made by each team member and is recorded all the time we were working about the design document, this includes planning, team organization, reading and learning how to develop the different parts of the document, writing the document and other activities that were done to develop this document.

\vspace{0.5cm}

\begin {itemize}
	\item \text Adrien Bestel documented to have worked 17 hours.
	\item \text Jorge Vera documented to have worked 15 hours.
\end {itemize}
\vspace{0.5cm}
Therefore the total amount of worked hours by the team is 32 hours.


\end{document}